components/heroku/common/constants.mjs (1)

1-42: Add JSDoc documentation and group related events.

The implementation correctly defines all major Heroku webhook event types with clear descriptions. Consider these improvements for better maintainability:

+/**
+ * @typedef {Object} HerokuEntity
+ * @property {string} value - The webhook event identifier
+ * @property {string} label - Human-readable description of the event
+ */

+/**
+ * Supported Heroku webhook event types
+ * @type {HerokuEntity[]}
+ */
 const ENTITIES = [
+  // Add-on related events
   {
     value: "api:addon-attachment",
     label: "addon-attachment - An add-on has been attached or removed from the app",
   },
   {
     value: "api:addon",
     label: "addon - An add-on for the app has been newly provisioned or deleted, or its details have been modified",
   },
+  // Application and build events
   {
     value: "api:app",
     label: "app - The app itself has been provisioned or deleted, or its details have been modified",
   },
   // ... rest of the events

components/heroku/sources/new-webhook-event-instant/new-webhook-event-instant.mjs (1)

11-27: Consider adding validation for required props.

While the props are well-structured, consider adding explicit required: true to the appId prop definition since it's essential for webhook subscription.

 appId: {
   propDefinition: [
     heroku,
     "appId",
+    {
+      required: true,
+    },
   ],
 },

components/heroku/sources/new-webhook-event-instant/test-event.mjs (3)

1-2: Consider adding JSDoc comments to document the test event structure.

The event metadata follows Heroku's webhook format correctly. However, adding documentation would help developers understand the purpose and structure of this test event.

+/**
+ * Sample Heroku webhook event for testing.
+ * Represents an app update event with minimal test data.
+ * @see https://devcenter.heroku.com/articles/app-webhooks#events
+ */
 export default {

Also applies to: 42-48

---

3-37: Enhance test data quality for better testing coverage.

While sensitive fields are properly sanitized, consider:

1. Using realistic test values for non-sensitive fields (e.g., name, region, stack)
2. Adding comments to indicate which fields are intentionally empty

 "data": {
   "id": "9a4eaeed-24cc-4b23-a8ca-7867b251eaf3",
   "acm": false,
-  "name": "",
+  "name": "test-app-123", // Example test app name
   "team": null,
   "owner": {
     "id": "7b25912d-b147-48d6-b03d-f0fc72be381b",
-    "email": ""
+    "email": "" // Intentionally empty for privacy
   },

---

49-53: Document the purpose of previous_data.

The structure correctly tracks changed fields, but it would be helpful to document why only these specific fields are included.

+  // Track changes to key fields for testing update scenarios
   "previous_data": {

components/heroku/heroku.app.mjs (3)

33-35: Simplify parameter destructuring in _makeRequest method

The default parameter $ = this within the destructuring assignment may reduce readability for some developers.

Consider restructuring the parameter assignment for clarity:

  _makeRequest(opts = {}) {
+   const { path, ...otherOpts } = opts;
+   const $ = opts.$ || this;
    const {
-     $ = this,
-     path,
-     ...otherOpts
    } = opts;

---

52-60: Add parameter validation in createWebhookSubscription method

The createWebhookSubscription method assumes that appId is provided. Adding a check to validate that appId is present can prevent potential runtime errors.

Consider adding a parameter validation:

  createWebhookSubscription({
    appId, ...opts
  }) {
+   if (!appId) {
+     throw new Error("appId is required to create a webhook subscription.");
+   }
    return this._makeRequest({
      method: "POST",
      path: `/apps/${appId}/webhooks`,
      ...opts,
    });
  },

---

61-68: Add parameter validation in deleteWebhookSubscription method

Similarly, ensure that both appId and hookId are provided in the deleteWebhookSubscription method to prevent errors when deleting a webhook.

Consider adding validation for these parameters:

  deleteWebhookSubscription({
    appId, hookId, ...opts
  }) {
+   if (!appId || !hookId) {
+     throw new Error("Both appId and hookId are required to delete a webhook subscription.");
+   }
    return this._makeRequest({
      method: "DELETE",
      path: `/apps/${appId}/webhooks/${hookId}`,
      ...opts,
    });
  },

Configuration used: CodeRabbit UI
Review profile: CHILL

#!/bin/bash
# Description: Verify the usage of ENTITIES constant in related files

# Test 1: Check if ENTITIES is imported and used in the app component
echo "Checking app component integration..."
rg -l "import.*constants" components/heroku/heroku.app.mjs
rg "ENTITIES" components/heroku/heroku.app.mjs

# Test 2: Check if ENTITIES values are used in webhook component
echo "Checking webhook component integration..."
rg "api:[a-z-]+" components/heroku/sources/new-webhook-event-instant/

#!/bin/bash
# Check the webhook component implementation for ENTITIES import and usage
echo "Checking webhook component imports and implementation..."
rg -l "import.*constants" components/heroku/sources/new-webhook-event-instant/
rg "ENTITIES" components/heroku/sources/new-webhook-event-instant/ -A 2

# Check if there are any other files using these constants
echo "Checking other potential usages..."
rg "api:(addon-attachment|addon|app|build|collaborator|domain|dyno|formation|release|sni-endpoint)" --type js

#!/bin/bash
# Check the webhook component's source code
echo "Examining webhook component implementation..."
cat components/heroku/sources/new-webhook-event-instant/new-webhook-event-instant.mjs

# Check if there are any prop type validations
echo "Checking for prop types or schema validations..."
rg "prop-types|schema" components/heroku/sources/new-webhook-event-instant/ -A 3

#!/bin/bash
# Description: Search for other test events to ensure consistent structure
# and verify against Heroku's documentation patterns

# Test: Look for other webhook test events in the codebase
fd -e mjs -e js 'test-event' -x rg -l 'webhook_metadata'

# Test: Search for webhook structure documentation
rg -i 'webhook.*metadata|delivery.*metadata' README.md docs/

#!/bin/bash
# Let's search for any webhook-related patterns in the codebase to understand the structure
rg -A 5 -B 5 'webhook.*metadata|delivery.*metadata' --type js --type mjs

# Also search for any webhook documentation or schema definitions
fd -e json -e schema.mjs 'webhook|schema' -x cat {}

#!/bin/bash
# Search for webhook patterns in the codebase, including the file extension explicitly
rg -A 5 -B 5 'webhook.*metadata|delivery.*metadata' -g '*.{js,mjs}'

# Look for any schema or type definitions related to webhooks
rg -A 10 'webhook.*interface|webhook.*type|webhook.*schema' -g '*.{js,mjs,ts}'

# Search specifically in the Heroku component directory for webhook-related files
fd . components/heroku -x cat {} | rg -A 5 -B 5 'webhook'

#!/bin/bash
# Description: Verify that 'ENTITIES' is exported from 'constants.mjs'

# Search for the export of 'ENTITIES' in 'constants.mjs'
rg 'export\s+const\s+ENTITIES' ./common/constants.mjs

#!/bin/bash
# Let's first find where constants.mjs might be located
fd -e mjs -e js constants

# Then search for ENTITIES export in all JS/MJS files
rg -l "export.*ENTITIES" --type js

#!/bin/bash
# Let's check the content of the Heroku component's constants file
cat components/heroku/common/constants.mjs

# Also check if ENTITIES is defined in the file being reviewed
cat components/heroku/heroku.app.mjs